Hi SJH,

Regarding EStop: EStop is not intended to be recoverable.  It kills/aborts everything immediately and leaves things in an unpredictable state.  It is up to the operator to re-initialize and start from a valid new line of GCode.  I suppose we might add some sort of warning if the Operator attempts to resume from some line of GCode other than the beginning of a file.  There is a "Set Next Line" option that may help in some cases.

However Halt should perform an immediate Feedhold, decelerate to a stop in a controlled manner along the path, and be resume-able with no issue.  The Axes should remain enabled.  Could you change or add a Halt button to your system to be used in those cases?

Regarding Closed Loop Scales: I think using Halt instead of EStop should solve this problem.  But what you might do additionally is modify how your axes are enabled as well.  Normally after an axis has been disabled the axis might have been moved manually or coasted to a new position so the last Dest (servo target command position) can not be left the same as this could result in a violent jump back to this position.  Instead the current Encoder Position is used as the new Dest which avoids any violent jump.  So what you might do instead is check whether the current Encoder Position is "close" to the last Dest.  If so, then it is safe to Enable the axis to the last Dest, otherwise Enable the axis to the Encoder Position.

HTH
Regards
TK

 

Hi Tom,

The following g-code subroutine shows a problem if there is an estop in the blocks with no explicit G1.  When resuming, it does not backtrack to determine that the motion mode was G1.  Instead, it thinks it was G0 so the remaining moves are done at rapid (!) until it sees the next G1.

f1000

g53 g0 z0

x0 y0

m98 p100 L100

g53 g0 z0

m2

o100

g1 z100

x10

y10

x0

y0

g0 z110

m99

If I put an explicit G1 on the moves in the subroutine, then it recovers OK.  Although I have it coded as a subroutine here, the same behavior is observed for "straight-line" code.

Our Estop input is a hardware switch on the kflop, which we use to disable axes, which is picked up by KMotionCNC as usual.

On a related note, we use linear feedback scales, which makes the estop recovery a little unpredictable: sometimes the dialog pops up, sometimes not.  I think this might be because the scales may randomly move a few um - if the coordinates are not exactly the same then the resume dialog will pop up.  Maybe there needs to be a parameter to allow a bit of axis movement so that the dialog does not pop up unless there is definite movement from the halted position.

We also had a bad crash last night (which is why we are looking at this in detail).  Same deal, running a program which does a lot of drill cycles with 5-axis (indexing) mode.  We used the estop to halt the program, then I accidentally hit cycle start (where I actually intended to rewind the program).  Rather than just resuming the program, it appeared to restart the program anyway, but everything was scrambled.  Although we have a g53 Z safe move at the start of the program, it seemed to skip over that and went straight to zeroing the A,B axes.  Of course, the drill was right near the workpiece at that point, so it got smashed up.

Unfortunately, that program is rather complex so I can't reproduce it.  It also has probing cycles, so it is not practical to run "in the air".  But I did notice a few times that running the above snippet would behave oddly (including seeming to run from the start) but I can't reproduce the behavior.

Regards,

SJH